Helpfeel Tech Conf 2024 - hiroshi 登壇資料 - Gyazo 開発 Platform Engineering
自己紹介
https://gyazo.com/d62755b688c3abf78d3deade83898e1e
主な情報入手ルートは毎朝の HackerNews top 30
hiroshi.icon 国内の話題は情弱です
Gyazo のプロダクトエンジニア
器用貧乏なのでサーバーサイドとかインフラを担当
サーバー管理とか mutable な環境嫌いなのでコンテナなど immutable なのが好き
https://nota.gyazo.com/4efaad4c46943019acd1dff003942662
Night gathers, and now my watch begins.
hiroshi.icon このフレーズにピンと来たら懇親会でお話ししましょう
Platform Engineering とは?
よくわかってません
SRE も
僕の理解では...
広い意味でプロダクトのユーザーに価値が直接届かないような作業
自分を含めたエンジニアが快適に作業できるようにする工夫全般
DevOps とかも含む
ふつうにみんなやってること
やりすぎると AWS が誕生しちゃうらしい
hiroshi.icon GCP の P も Platform ですね
日本語で「基盤」と言ってしまうとちょっと違う感じがする
前提知識として
Gyazo の歴史
Gyazo の開発環境
Gyazo の production 環境
Gyazo の CI/CD
Gyazo 開発/運用の歴史
2007 増井さんが個人サーバーでサービス開始
perl か ruby CGI みたいな実装
2009ごろ? 旧 nota 社の事業として引き取る
PHP になった?
Storage は S3
2014 Rails + Go
一部 heroku もあったり
2015 GCE (Google Compute Engine)
Srorage も GCS (Google Cloud Storage)
2020 GKEにほぼ移行
hiroshi.icon あれ? こんな最近だっけ? M1 MacBook Air もその年末だし
GKE (Google Kubernetes Engine)
Kubenetes は docker image などのコンテナ管理ツールの defact standard みたいなやつです
もうちょいで 20年
hiroshi.icon 自分の子供は 2006年生まれなので同世代だ...
Gyazo の開発環境
2016ごろから主に mac か windows で Docker Desktop
最初は MongoDB だけとか
2020 GKEで deploy している同じ Dockerfile で開発できるように
docker compose で必要なものは揃うはず
ruby, node.js とか native install は必須ではない
Gyazo の production 環境
今はほぼ GKE に集約できてます
(upload とか画像/動画 バイナリ扱うやつは golang)
cronjob や background job (delayed_job)とかも
staging も別の GKE cluster がある
Gyazo の CI/CD
git flow みたいなやつ
一般的には development ブランチから feature X ブランチ派生で development から main ブランチにマージでリリースだと思います
Gyazo では main から featrure ブランチで main から production にマージするとリリースされる
こういう github actions workflows で
main にマージされると release PR と呼ばれるものが作られて
production ブランチにマージされると tag 付けて github release を作成
hiroshi.icon 実は main でなく master のままだけど...
deploy は google cloud build
ブランチによって deploy 先を変更...
hiroshi.icon 個人的に Makefile 的にシンプルな Cloud Build 好きでローカルで実行できるやつ作ったりしてました
Gyazo 的解釈の Platform Engineering
現場の雰囲気を感じたり、なるほど、みたいに思ってもらえると幸いです
ぶっちゃけそれがベストかどうかわからんのでもっといい方法があったら後で教えてください
具体的な取り組みをいくつか紹介します
① 開発環境の MongoDB バージョンアップ支援
② production/staging の rails console (REPL)
③ one-off batch 処理は branch で background job 作って実行
④ action-cov (CI)
開発環境の MongoDB バージョンアップ支援
「開発環境でもMongoDBのバージョン更新するので各自以下のコマンドで featureCompatibilityVersion を更新してください」とか slack で伝えても、後日「docker compose の MongoDB 起動しなくなった」みたいなことになる
ローカルの rails 起動時に自動で設定してしまえば OK
code:config/environments/development.rb
# Confirm MongoDB Featurecompatibilityversion
def mongodb_feature_compatibility_version
Gem::Version.new(Mongoid.default_client.use('admin').command({ getParameter: 1, featureCompatibilityVersion: 1 }).first.dig('featureCompatibilityVersion', 'version'))
end
config.after_initialize do
version = mongodb_feature_compatibility_version
if version < Gem::Version.new('5.0')
Rails.logger.info "MongoDB featureCompatibilityVersion: #{version} -> 5.0" Mongoid.default_client.use('admin').command({ setFeatureCompatibilityVersion: '5.0' })
end
end
hiroshi.icon 自分でも 5.0 は定数とかにしたいよねと思ってます
と思ってたら nonaさんが 6.0 更新時にやってくれた!! エライ hiroshi.icon 開発環境の MongoDB を cluster にして transaction 使えるようにするための one-off docker compose service とかもあるんだけど、同様の方法でできないかな?
production/staging の rails console (REPL)
開発環境だったら
code:sh
docker compose run --rm app bundle exec rails console
GCE みたいなサーバーでも ssh すればよい
heroku にも heroku run がある
GKE の場合、同じ image の pod(コンテナ)を作れば(ほぼ同じ環境になる)
code:sh
kubectl \
run gyazorails-console-$USER \
--image=XXXX/gyazo/gyazorails:master \
--image-pull-policy=Always \
--env=RAILS_ENV=staging \
--env=GYAZO_BRANCH=master \
-ti --rm \
--overrides='{ "spec": { "serviceAccount": "gyazorails" } }' \
bundle exec rails c
ServiceAccount では足りない secret へのアクセスなど必要な場合は kubectl exec で実際に request を捌いているコンテナに入ったりもします
このへんは kuberntes 使ってればみんなやってることだとは思いますが...
hiroshi.icon 現代では GKE でなく Cloud Run もありますが、上記のような run 的な機能で REPL できないみたい
one-off batch 処理は branch で background job 作って実行
時間のかかるone-off (使い捨て) batch 処理を実行したいときがある
console だとコケたりしたりときのやり直しとか気を抜けない
そのままだと数日かかっちゃうやつは並列化したい
background job のしくみを使うと便利
GKE (kubernetes) の job じゃないです
Gyazo ではブランチごとに background job (delayed_job) の queue を分離
feature branch でも専用の delayed_job の deployment (pods) が存在
そのブランチで rails console 起動して TheJob.perfom_later(...)
ログは GKE log で残るし
並列実行したいときは kubectl scale --replicas=10 ... とかで増やして
10.times{|n| TheJob.perform_later(n) } とかする
pull request レビュー受けられるし、 one-off だったらマージしない
action-cov (CI)
まじめに test corverage とかやるのはアホらしい
Rails の新しい controller#action 追加したのにテスト書かない輩にいちいちレビューで指摘するのが面倒
rspec 実行するときに #{controller}##{action} みたいなのを保存
最後に routes と比較して足りないやつを指摘
hiroshi.icon job とかテスト無いときがあるのでこれも指摘できるようにしたい
同じような感じで localization の key の過不足指摘するやつも i18n-tasks を使って実装
他には?....
feature branch の deploy (preview app みたいなやつ) とかの話や
deploy したら slack 通知で rolllback のやり方通知したりとか...
上記 on-off batch 処理のやつもこれの応用
staging の TLS cert を certbot で Google HTTP Load balancer に設定する k8s cronjob の話とかもあったりするのでまたいつか... (wildcard なので google managed は使えないと思っている)
まとめ
自社サービスプロダクトのエンジニアやってますが、自分が欲しいものしかわからない
hiroshi.icon 自分が使わないプロダクト/機能のユーザーがを欲しいものを想像するの苦手
Gyazo, Cosense は仕事でも private でも使う
こういう開発支援はターゲットが自分とその仲間なのでめっちゃモチベーションが上がる
そういう積み重ねでプロダクトのユーザーにも価値が提供できるといいなと思います